Method and system for transport of frame relay traffic over satellite/wireless networks

ABSTRACT

To efficiently transmit frame relay packets between terrestrial frame relay networks ( 10, 12 ) over a satellite/wireless network ( 14 ), the packets are processed by frame relay processors ( 16, 18 ) at both ends of the satellite/wireless network ( 14 ). Variable length frame relay packets are segmented into smaller packets called spackets. The system utilizes priority queueing and a scheduler ( 24 ) transmits the spackets over the satellite/wireless link. To enhance the quality of the satellite/wireless link, each frame contains a variable number of Reed-Solomon (RS) check bytes used for error correction. Further, several frames are interleaved before transmission over the satellite/wireless link to spread the effect of burst errors over several frames. Additionally, a header compression technique saves bandwidth by compressing a Virtual Circuit (VC) identifier of the frame relay packet into a smaller value and maps the VCs to a value as specified by the size of the compressed VC field.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority from U.S. Provisional Application Ser.Nos. 60/062,496, 60/062,497 and 60/064,673, filed Oct. 20, 1997. Thedisclosures of these provisional patent applications are incorporatedhereby by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method and system for transportingframe relay packets of data over satellite or wireless communicationlinks, and, in particular, to a method and system employing a robust,flexible frame format to efficiently transmit data under varying linkand data traffic conditions.

2. Description of the Related Art

Transport of frame relay packets over satellite/wireless linksintroduces a number of technical issues that are not present interrestrial wireline links. First, satellite/wireless links tend to bemuch more noisy than terrestrial wireline links. Consequently,satellite/wireless links require the use of error correcting techniques.Second, the bandwidth on a satellite/wireless link is a scarce resource.In the event of data traffic congestion, consideration must be given tothe priority of the data being transmitted, with high priority trafficbeing given preference over low priority traffic. Data compression canalso be employed to better utilize available bandwidth. Third, unlikeasynchronous transfer mode (ATM) cells, frame relay packets are variablelength. Thus, the frame formats used to communicate betweensatellite/wireless terminals need to be able to transport variablelength packets efficiently. Fourth, carrying prioritized data over lowbandwidth links creates certain problems. Assume that the transmissionof a large, low priority packet has just begun. If the link bandwidth islow, then it may take a long time for the packet to transmit. A highpriority packet may then have to wait for an intolerably long period oftime before being transmitted.

There are no known systems specifically tailored to address the uniqueissues relating to transport of frame relay packets oversatellite/wireless links. Traditionally, frame relay traffic has beentransported over satellite/wireless links by directly connecting framerelay switches to satellite/wireless modems without significantprocessing to ensure efficient and timely transmission of data over thelinks. Thus, the present use of satellite/wireless links to transportframe relay data can significantly limit the performance of the framerelay networks.

SUMMARY OF THE INVENTION

It is an object of the present invention to efficiently transmitvariable length packets of data, such as frame relay packets, oversatellite/wireless links, while addressing the data transmission issuespresented by transport of such packets over satellite/wireless links.

It is another object of the present invention to avoid the excessivedelay of high priority data over satellite/wireless links having limitedbandwidth resources by efficiently segmenting and scheduling frame relaypackets of different priorities.

It is yet another object of the present invention to minimize dataerrors caused by the relatively noisy communication medium ofsatellite/wireless links without introducing excessive transmissionoverhead by using a dynamic, robust error correction technique that isresponsive to varying link conditions.

It is a further object of the present invention to maximize the use ofavailable bandwidth by judiciously employing data compression totransmit data over satellite/wireless links.

The aforesaid objects are achieved individually and in combination, andit is not intended that the present invention be construed as requiringtwo or more of the objects to be combined unless expressly required bythe claims attached hereto.

To achieve these objects, the system of the present inventionefficiently transports frame relay traffic over satellite/wirelessnetworks utilizing several techniques. According to the presentinvention, variable length frame relay packets are segmented intosmaller packets called “spackets” to provide for efficient scheduling ofpackets of different priorities. A frame may carry severalvariable-sized spackets, or a single spacket may be carried over severalframes. In this manner, high priority packets can avoid delays due tolarge, low-priority packets, because spackets belonging to a highpriority packet can be transferred after a single spacket belonging to alow-priority packet is transferred.

Further, Virtual Channels (VCs) can be configured to enable datacompression such that spackets belonging to a VC are passed through adata compressor/decompressor combination to save bandwidth. The systemalso utilizes priority queuing, wherein VCs can be configured to beeither high or low priority, and a scheduler uses this information tofairly transmit the various spackets over the satellite/wireless link.The use of spackets to reduce the delays experienced by high prioritypackets allows for efficient implementation of compression anddecompression modules.

The frame format of the present invention also allows fastsynchronization and the exchange of coding information. To enhance thequality of the satellite or wireless link, each frame containsReed-Solomon (RS) check bytes used for error correction, that can beadaptively changed based on varying link conditions. The number of RScheck bytes in a frame can be changed on the fly, without any loss ofdata, to compensate for varying link conditions. The link quality ismonitored, and the observed link quality is used as the criterion forsetting the number of RS check bytes in a frame. Further, several framesare interleaved before transmission over the satellite/wireless link tospread the effect of burst errors over several frames, all of which canthen be corrected by the forward error correction (FEC) in the frames.

Additionally, a header compression technique is utilized to savebandwidth by compressing the VC identifier of a frame relay packet intoa smaller value and mapping the VCs to a value as specified by the sizeof the compressed VC Id field. This technique utilizes the fact that thenumber of VCs carried over the satellite/wireless link is not very largeand can be compressed to a much smaller VC identifier field.

The above and still further objects, features and advantages of thepresent invention will become apparent upon consideration of thefollowing detailed description of specific embodiments thereof,particularly when taken in conjunction with the accompanying drawingswherein like reference numerals in the various figures are utilized todesignate like components.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram illustrating the functionalrelationship of the present invention to a frame relay networktransmitting data over a satellite/wireless network.

FIG. 2 is a high-level functional diagram illustrating the variousfunctions performed by the additional frame relay processing module ofthe present invention.

FIG. 3 illustrates the fields contained in a spacket according to anexemplary embodiment of the present invention.

FIG. 4 illustrates the frame format of a satellite/wireless framestructure according to an exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 is a top-level block diagram illustrating how the processingperformed in accordance with the present invention relates to theoverall transport mechanism, wherein two-way transmission of frame relaydata between private/public frame relay networks 10 and 12 is carriedover a satellite/wireless network 14. According to the presentinvention, additional frame relay processing is performed between framerelay network 10 and satellite/wireless network 14 and between framerelay network 12 and satellite/wireless network 14, as indicated,respectively, by functional blocks 16 and 18 which represent additionalframe relay processing modules.

The additional frame relay processing techniques performed in accordancewith the present invention to efficiently carry frame relay packets oversatellite/wireless links include: frame relay processing at the physicallayer and the data link layer; formatting of data (variable lengthpackets, segmentation and reassembly, resequencing); dynamic forwarderror coding (FEC); interleaving of frames (to spread the effect ofburst errors); per-VC data compression; prioritization and scheduling;and header compression.

FIG. 2 is a high-level functional diagram illustrating the variousfunctions performed by the additional frame relay processing module 16between frame relay network 10 and satellite/wireless network 14.Similar processing is performed by additional frame relay processingmodule 18. The system of the present invention uses several innovativetechniques to efficiently transport frame relay packets oversatellite/wireless links. The system uses a robust, flexible frameformat between the two communicating terminals in which frame relay datapackets are segmented into smaller packets called “spackets.” Severalvariable-sized spackets can be transported in a frame, and a singlespacket can be transported over several frames.

The frame format allows fast synchronization and the exchange of codinginformation. Each frame contains Reed-Solomon (RS) check bytes that areused for error correction and to enhance the quality of thesatellite/wireless link. The number of RS check bytes in a frame can bechanged on the fly, without any loss of data, to compensate for varyinglink conditions. The decision to change the RS check bytes in a frame isbased on the results of constant monitoring of the link quality.Additionally, several frames are interleaved before transmission overthe satellite/wireless link to help spread the effect of burst errorsover several frames, all of which can then be corrected by the FEC inthe frames.

Further, virtual channels (VCs) can be configured to enable datacompression, so that spackets belonging to a VC are passed through adata compressor/decompressor combination to save bandwidth. VCs can alsobe configured to be either high or low priority VCs, and a scheduleruses this information to fairly transmit the various spackets over thesatellite/wireless link.

To minimize the large delays introduced by the transmission of lowpriority packets on a low bit rate link, and the delay experienced byhigh priority packets which are waiting to be scheduled, large packetsare segmented into several, smaller spackets. Because high priorityspackets can be transmitted after transmission of only a single lowpriority spacket, the delays experienced by high priority packets aresubstantially reduced. This also allows for efficient implementation ofthe compression and decompression modules.

Furthermore, to save bandwidth, header compression techniques areemployed to compress the VC Identifier (VC Id) of a frame relay packetinto a smaller value. This technique takes advantage of the fact thatthe number of VCs carried over the satellite/wireless link is not verylarge and can be uniquely represented by a small number, so that the VCIdentifier can be compressed to a much smaller VC Id field. The systemallows flexible configuration of various parameters in the system. Thefollowing are some of the configurable system parameters: Frame Size,Interleaver Depth, Enable/Disable Dynamic RS FEC, Set Max/Min Checkbytesfor the Dynamic RS FEC, Enable/Disable data compression, Priorities andCompression for various VCs, Enable/Disable Header Compression, andNumber of spackets between resetting the compression and decompressionhistories in the data compressor and the decompressor. Each of the abovetechniques is described in greater detail in the following sections.

1. Frame Relay Processing

As shown in FIG. 2, additional frame relay processing module 16 includesa frame relay physical and data link layer processor 20 that receivesthe frame relay packets from frame relay network 10. Frame relayphysical and data link layer processor 20 processes the frame relaypackets as specified in International Telecommunication Union (ITU)recommendation Q.922 (Link Access Procedures for Frame Relay). Thephysical layer processing is similar to the processing of any HDLC datastream. This is the processing performed in most Frame Relay AccessDevices (FRADs).

A frame relay packet received from the terrestrial network 10 consistsof payload data, a cyclic redundancy check (CRC) field, and flags at thebeginning and the end of the frame. The frame relay processor 20 removesthe flags and the CRC fields and transports only the payload section ofthe frame relay packet over the satellite/wireless link 14. The CRC andthe flag information is regenerated at the receiving terminal and addedto the packet in module 18 before it is transmitted to the receive sideterrestrial network 12.

2. Prioritizer/VC Identifier

The queuing of data to be transported over the satellite/wireless link14 can be based on priorities or virtual channels (VCs). In the formercase (i.e., queuing performed at the priority level), there are separatequeues for high and low priority data. VCs are configured to be eitherlow or high priority VCs. A prioritizer/VC identifier segmentationprocessor 22 adds cells received from the terrestrial network 10 to bepriority queues based on whether the VCs they belong to have beenconfigured as high or low priority. A scheduler 24 transmits cells fromthese priority queues. Cells in each priority queue are transmitted on afirst-in-first-out (FIFO) basis. With this queuing system, the issue offairness between VCs of the same priority cannot be addressed.

In the case of queuing performed at the VC level, per-VC queues aremaintained, which implies a separate queue for each VC. The schedulertransmits cells from all of these queues. In this case, the issue offairness among different VCs can be addressed. As shown in FIG. 2,prioritizer/VC identifier segmentation processor 22 generates separate,per-VC data queues and delivers these queues to scheduler 24.

If header compression has been enabled in the system, then the VCs aremapped into a new value as specified by the size of the compressed VCfield. This header compression information is periodically exchangedbetween the communicating terminals 16 and 18. Further, every time a newmapping is created, this information is asynchronously exchanged betweenthe terminals before the actual transfer of the mapped packet begins.

3. Segmentation Processor

Referring again to FIG. 2, prioritizer/VC identifier segmentationprocessor 22 segments the variable-length frame relay packets intoseveral smaller packets called spackets. These spackets allow efficientscheduling of packets belonging to multiple priorities and lossless datacompression. FIG. 3 shows the various fields contained in a spacket inaccordance with an exemplary embodiment of the present invention.

As mentioned above, a large, low priority packet, if transmitted overthe satellite/wireless network 14 as a single segment, will cause highpriority packets to wait until the entire transmission is completed.This transmission scheme introduces a significant amount of delayvariation into the high priority traffic. Such delay variation can beintolerable for traffic such as video and audio traffic which requirestringent delay variation from the network. Since spackets transferlarge frame relay packets as smaller segments, spackets belonging to ahigh priority packet can be transferred after only a single spacket froma low priority packet has been transferred, thus minimizing the delayvariance that the high priority packet experiences. This techniqueminimizes the delay variance significantly, and results in thesatellite/wireless network performance being better than that ofterrestrial networks with respect to delay variance.

Each frame relay packet is segmented to one or more spackets. If a framerelay packet is segmented into more than one spacket, then all but thelast spacket are n bytes long. The last spacket can also be n bytes longif the frame relay packet had a length which was an integral multiple ofn to begin with. A spacket is then prepended with a header as shown inFIG. 3. The spacket header contains the VC Identifier to which thepacket belongs. The header also contains the packet and the sequencenumbers. The packet number increments for each new frame relay packet.The sequence number increments for each spacket within the frame relaypacket. Information about the priority of the packets and whether or notthe packets are compressed is maintained locally. All this informationis used to perform segmentation/reassembly, datacompression/decompression, prioritization and scheduling. The spacketheader also contains a “last field” which indicates whether or not thespacket is the last spacket for the frame relay packet. If spacket isthe last spacket for the frame relay packet, then, at the receivingterminal 18, the frame relay packet can be reassembled and transmittedover the terrestrial link 12.

The sizes of the various fields within the spacket can be set inaccordance with the specific requirements and design parameters ofparticular networks. The VC Id field can either be the size of theentire VC field in the frame relay packet or can be the size specifiedin the header compression parameters. The size of the Packet number andSequence number fields are also set in accordance with the systemdesign. The “last field” is preferably a single bit.

The size of the payload is determined by a trade-off between theoverheads and the performance of the system. If the payload size is verylow, the overheads will be very high (resulting in reduced payloadthroughput per transmitted bit), but the delay variance performance ofthe system will be very good. If the payload size is set to a largevalue, then the delay variance performance will be poorer but theoverheads will be lower (resulting in higher payload throughput pertransmitted bit). Hence, the sizes of the overhead and payload fields ofthe spacket are set in accordance with system performance specificationssuch as permissible delay variances and throughput efficiencyrequirements.

4. Per-VC Queues

As shown in FIG. 2, queues of spackets belonging to different VCs arestored for use by scheduler 24. As described in section 2, the queuescan be based on priorities or VCs. In the former case, queues for thepriorities are maintained, and the cells in each priority queue aretransmitted on a FIFO basis. The more preferable mode of queuing is tohave a queue for each VC, and to store the cells belonging to each VC inits corresponding queue. Cells in these per-VC queues are alsotransmitted on a FIFO basis to preserve sequence integrity. Scheduler 24is designed to be fair to VCs within a priority as well as betweenpriorities.

5. Scheduler

The scheduler sends spackets belonging to various VCs over the satelliteor wireless link 14. If the spacket is to be compressed, the spacket isfirst sent to a Data Compressor 26 (FIG. 2). Scheduler 24 uses all thepriority information for the various VCs and attempts to be fair in thescheduling of the spackets. A simple scheduling algorithm which can beemployed by scheduler 24 is to process all the high priority per-VCqueues on a round-robin basis and then to process all the low priorityper-VC queues on a round-robin basis. Another scheduling option is forscheduler 24 to transmit at least one low priority cell every n highpriority cells. This assures some degree of fairness between priorities.A further option is to use, within a priority, a weighted round-robinscheduling algorithm to transmit cells from per-VC queues, with theweights reflecting the bandwidths for which the VCs have subscribed.This scheduling algorithm attempts to schedule different VCs fairly.

6. Data Compressor

As shown in FIG. 2, spackets that belong to a VC which has beenspecified to be compressed are compressed by the data compressor 26. Toachieve loss-less data compression, the compression and decompressionhistories are reset every n spackets, where n is a configurable, integerparameter. With the FEC, the link is maintained at a very low byte errorratio (BER). If a spacket does get corrupted, then the resetting of thehistories will ensure that not more than n spackets are affected.

7. Satellite/Wireless Frame Processor

According to another aspect of the present invention, a unique framestructure is used to transport data from frame relay packets over thesatellite/wireless link. This frame structure is designed to facilitatefast frame synchronization, accommodation of several variable-sizepackets, fast recovery from lost frames, very low bandwidth overhead,and dynamic Reed-Solomon coding changes without introducing data lossduring the coding rate change transition. FIG. 4 illustrates the frameformat of the satellite/wireless frame structure according to anexemplary embodiment of the present invention.

The fundamental unit of transmission over the satellite/wireless link isa fixed size frame that is n octets long. If an interleaving depth of Iis used, then I such frames are used to compose an “interleaver frame.”A satellite/wireless frame processor 28 (FIG. 2) rearranges the order ofthe bytes in the interleaver frame and transmits each byte sequentiallyover the satellite/wireless link 14. Note that there are no specialsynchronization bits in the frame structure shown in FIG. 4.

Each frame is n bytes long and includes a 2-octet header followed by theframe payload, and is terminated by 2t octets (t>0) of Reed-Solomoncoding check bytes at the end of the frame. The payload contains acombination of several variable-size packets (the packets may containcompressed or uncompressed spackets).

The rules for filling a frame payload with spackets are as follows:

-   -   1. If the previously transmitted frame contained a partial        spacket at the end of the payload, the frame payload currently        being transmitted begins with the next portion of that spacket.        This portion shall consume min(4*size0, payload_size) octets of        the payload, where size0≧0. The actual size of this partial        spacket may be up to three octets less than 4*size0, in which        case the extra octets shall be filled with zeroes.    -   2. After the initial partial spacket segment, the payload        contains count0 spackets where count0≧0. If the last Spacket        cannot be entirely contained in the payload, then only its        initial portion is included in the payload. Each spacket is        preceded by a 1-octet-length (in octets) field followed by the        spacket contents. The length field contains the size of the        spacket in bytes.    -   3. If there are any octets left over in the payload, then the        first such unused octet shall contain a zero. The rest of the        octets, if any, shall be filled sequentially with the numbers i,        i+1, i+2 where i is the octet number of the first such octet in        the payload (octets in the payload are implicitly numbered 0, 1,        . . . ).

From these rules, it can see that a frame payload may contain severalspackets and that the spackets can be transmitted over more than oneframe. A frame with no spackets contains the sequence 0, 1, 2, . . . inthe payload. A spacket may be split across more than two frames ifrequired. This frame structure design allows the possibility ofdynamically changing the Reed-Solomon error correction code size bycorrespondingly changing the payload size, while keeping the frame sizeconstant. If the receiver “loses” a frame, for example, due to excessivebit errors in the frame, the size0 field allows rapid determination ofthe spacket boundary on the very next frame.

The frame header of the satellite/wireless frame structure shown in FIG.4 has four fields which are described in Table 1.

The Read-Solomon checkbytes inserted at the end of each frame are thecheckbytes generated by a standard Reed-Solomon algorithm with framesize=N bytes and number of checkbytes=2t. During the time that thesystem has not achieved receive synchronization, the system sets theReed-Solomon code value of its receiver and its transmitter to themaximum value. After the system achieves receive synchronization anddetects that the remote terminal has also achieved receivesynchronization (i.e., the coding field in the received frame header offrame number 0 contains a valid code value), the adaptive codingalgorithm is activated, as described below.

TABLE 1 Description of the Fields in the Header of theSatellite/Wireless Frame Count0 Number of Spackets in frame. Does notinclude the first Spacket, if any. Includes the last Spacket, if any.Size0 Size of first partial Spacket in frame divided by 4. Frame Theframe number. Num Each frame is sequentially numbered 0, 1,. . ., 7, 0,.. . Coding If FrameNum > 3, the coding field represents the number ofReed-Solomon octets/2 that will be used starting with the next framenumbered 0. Note that 0 is an invalid value for the coding field. IfFrameNum == 0, the coding field represents the suggested value of thenumber of Reed-Solomon octets/2 that the other side should use for itsown transmission. If the coding field value is 0 × F, the value impliesthat the transmitting terminal is not yet synchronized to its receivingbit stream. Note that 0 is an invalid value for the coding field. IfFrameNum == 1, the least significant bit of the coding field is 1 ifspacket header compression is activated at the transmitting terminal, 0otherwise. Other bits of the field are reserved for future use. IfFrameNum is 2 or 3, the coding field shall be set to 0's.7.1 Bit Error Ratio Measurement Algorithm

The bit error ratio measurement algorithm in accordance with anexemplary embodiment of the present invention is as follows.

-   1. Whenever the system receiver achieves synchronization, it    initializes the following variables as shown below.    -   BER=10⁻³    -   MINBER=1/715827880-    Variable BER is the “byte error ratio”, not the bit error ratio.    The bit error ratio is approximately equal to BER divided by 8,    assume a single bit error per byte.-   2. While the system receiver is in synchronization, the algorithm    performs the following computation once per second:

nbytes = total number of bytes received since the last time thiscomputation was done nerrors = total number of (byte) corrections madeby the Reed-Solomon decoder i since the last time this computation wasdone if nerrors < 8 and nbytes <1 / BER *4 and nbytes <1 / MINBER*2return --accumulate more data and try again later if nerrors <= 0nerrors = 1 currBER = nerrors / nbytes if currBER > BER --worse? BER=1 /((1 / BER+ 1 /currBER*3) / 4) -- fast filter else if 1 / currBER> 1 /BER * 5 / 4 BER = 1 / (1/ BER +1 / currBER / 32) -- very slow filterelse BER = 1/ ((1 / BER * 7 + 1 / currBER) / 8) - slow filter endifendif if BER < MINBER BER = MINBER

The algorithm measures BER very accurately. The measurement is performedvery quickly when BER is high. When BER is low, the algorithm takeslonger between computations, since it takes longer periods of timebefore sufficient bit errors accumulate to make an accurate computation.

The “filter” parameters in the above algorithm have been chosen in a waythat the algorithm reacts quickly to deteriorating BER and reacts slowlyto improving BER. These parameters can be changed to get differentreaction times. Other alternate filter algorithms can be used dependingon the link error characteristics.

The above algorithm can be efficiently implemented in software usinginteger numbers only by maintaining the inverse value of BER and currBERas integer numbers between 1 and 2³².

7.2 Reed-Solomon Code Value Selection Algorithm

The follow algorithm is used if adaptive Viterbi code control is notused, i.e., only Reed-Solomon coding is adaptively changed. Once a BERcomputation has been done, the Reed-Solomon code value appropriate forthat BER is computed by the following algorithm.

Initialization:

-   -   codeindex=0        Reed-Solomon Code Value Computation:

The table codetable shown below and the computed BER value are used tocompute the code value. Each entry in the codetab table has two fields:the inverse of a BER value (BER) and the corresponding Reed-Solomon codevalue (number of checkbytes).

The codeindex variable is modified as follows:

while codeindex > 0 and 1/ BER >= codetab[codeindex − 1].BER_(—)−−codeindex while codeindex <codetable size and 1/ BER <=codetab[codeindex + 1]. BER_(—) ++codeindex

The code selection is done as follows:

code = codetab[codeindex].code codetab = {715827880,2}, {562241498,4},{20133667,4}, {6636252, 6}, {1078755, 6}, {635218, 8}, {219936, 8},{154438, 10}, {69463, 10}, {53221, 12}, {29402, 12}, {24125, 14},{14790, 14}, {12779, 16}, {8859, 16}, {7841, 18}, {5782, 18}, {5224, 20}

The above table values have been derived assuming that bit errors arebursty with an average burst length of 64 and a burst error densitywithin a burst of 20%. For random bit error situations, the errorintroduced by the use of this table is small; however, a similar tablecan be derived and used for such cases.

The table values and the code selection algorithm have been designed sothat there is an appropriate amount of hysteresis, so that if the BERfluctuates near a threshold value, the algorithm does not rapidly selectalternate values around the threshold value. The table values have alsobeen derived so that the net link quality after Reed-Solomon correctionis 10⁻¹⁰. The figure 10⁻¹⁰ represents the ratio of the spackets that arelost due to uncorrectable bit errors to the total number of spackets.

The table values have been derived so that there is a 0.5 decibel amountof “margin” built into the link quality measurement, i.e., even if thelink signal to noise ratio drops by 0.5 decibels, the link quality willbe maintained at 10⁻¹⁰. Hence, the actual quality experienced byapplications is better than 10⁻¹⁰ most of the time.

7.3 Reed-Solomon Code Value Exchange Algorithm

The computed value of the Reed-Solomon code value is sent over thesatellite/wireless link 14 in the coding field of each transmitted framewhose frame number is 0. The actual value sent in the coding field isthe code value divided by 2.

7.4 Reed-Solomon Code Synchronized Change Algorithm

The system monitors the value of the coding field of every receivedframe whose frame number is 0. If the received value is a valid codevalue between 1 and 10 and is different from the value currently beingused for the system's transmitted frames, then, in the next transmittedframe having a frame number of 4, the coding field in the frame headeris set to the new code value. This new value is repeated in all framesthereafter. Frames are transmitted using the old value of theReed-Solomon code until the next frame numbered 7. The next framenumbered 0 and all frames thereafter are transmitted using the new valueof the code. As an option, the transmitting terminal may modify thereceived code value to lie within certain configurable minimum andmaximum values before implementing code changes. The boundary within theframe between the payload and the Reed-Solomon field (see FIG. 4) isappropriately set.

A terminal monitors the value of the coding field of every receivedframe whose frame number is greater than or equal to 4. If the receivedvalue is non-zero and is different from the value being used for theterminal's receive frames, then, after the next (or current) receivedframe having a frame number of 7, (i.e., just before the receipt of thenext frame numbered 0), the Reed-Solomon decoder is programmed for thenew value of the Reed-Solomon code. The boundary within the framebetween the payload and the Reed-Solomon field (see FIG. 4) isappropriately set.

7.5 Extensions for Viterbi Coding Control

The system can be used for Viterbi coding control as well asReed-Solomon coding control. Such a system can use a combination ofViterbi and Reed-Solomon codes. The basic algorithm for setting thenumber of Reed-Solomon check bytes remains the same (see Section 7.2),although a different code table codetab is used. This table has valuesfor both the Viterbi code and the Reed-Solomon code in each entry, alongwith the BER inverse value. The exact values for each entry in the table(not shown) are derived using similar principles as is done for theabove table that does not use Viterbi code control. The firstapproximately 20 entries use Viterbi code rate 1; the next approximately20 entries use Viterbi code rate 7/8; the next approximately 20 entriesuse Viterbi code rate 3/4, and so on. Not all Reed-Solomon code valuesget used for each Viterbi code rate.

Whenever a new code rate is selected, both the Viterbi code value andthe Reed-Solomon code values are sent to the remote device. Viterbi codechanges, in general, may cause the receive modem to lose datasynchronization, leading to loss of frame synchronization in theterminal. In such a case, the receiving terminal shall not change itsreceive Viterbi and Reed-Solomon code rates for up to N (e.g., N=4)seconds after a Viterbi change. The transmitting terminal shallsimilarly retain its Viterbi and Reed-Solomon code rates for N secondseven if the transmitting terminal detects that the remote device haslost synchronization.

8. Data Decompressor

Frame relay processing module 16 includes a satellite/wireless framereceive processor 30 which receives data transmitted over thesatellite/wireless network 14 from processor 18 (FIG. 2). A datadecompressor 32 decompresses the spackets belonging to a VC which hasbeen configured to be compressed. Compression and decompressionhistories are maintained in data compressor 26 and decompressor 32,respectively. These histories are reset once every n spackets, where nis a configurable, integer parameter. This is done to minimize theeffect that a lost or erroneous spacket has on subsequent spackets.

9. Reassembly and Resequencing Processor

Once received by satellite/wireless frame processor 30 and decompressed(if applicable) by data compressor 32, a reassembly and resequencingprocessor 34 reassembles and resequences the data. Reassembly andresequencing processor 34 keeps track of spackets belonging to all theVCs. The reassembly algorithm works on a per-VC basis. The spackets foreach VC are resequenced based on the sequence and packet numberscontained in the spacket header (FIG. 3). The following rules are usedto reassemble frame relay packets:

-   -   1. If a spacket with a sequence number of zero is received,        discard any previous incompletely assembled frame relay packet        and start reassembling this new packet.    -   2. If a spacket with the same packet number and VC Id, with a        sequence number one more than the previous spacket is received,        then append this spacket to the partially reassembled frame        relay packet. If the “last field” indicates that the spacket is        the last spacket of a frame relay packet, the frame relay packet        has been completely assembled.    -   3. If a spacket having a non-zero sequence number which is out        of sequence is received, discard this new spacket and any        partially reassembled frame relay packet.    -   4. If the packet number of the spacket received is not the same        as that of the previous spacket and the sequence number of the        received spacket is not zero, discard this new spacket and any        partially reassembled frame relay packet.

Optionally, a length field can be added to the frame relay packet at thetransmitting terminal 16 before the packet is segmented and transmittedover the satellite/wireless link. This length field can be used at thereceiving terminal 18 to check if the frame relay packet has beenreassembled properly. If the frame relay packet has been properlyreassembled, the frame relay packet is added to the transmit queue.

10. Transmit Queue

As shown in FIG. 2, the transmit queue contains frame relay packetsreceived from the remote terminal 18 which will be transmitted over theterrestrial link 10. These packets are processed by the frame relayphysical and data link layer processing module 20 and transmitted overthe terrestrial link 10.

Having described preferred embodiments of a new method and system fortransport of frame relay traffic over satellite/wireless networks, it isbelieved that other modifications, variations and changes will besuggested to those skilled in the art in view of the teachings set forthherein. It is therefore to be understood that all such variations,modifications and changes are believed to fall within the scope of thepresent invention as defined by the appended claims.

1. A method of transporting frame relay data over a satellite orwireless network, comprising the steps of: receiving frame relay packetsfrom a frame relay network; prioritizing the frame relay packets;segmenting the payload data of each of the frame relay packets to formspackets; scheduling transmission of the spackets in accordance withpriorities of the frame relay packets to which the spackets correspond;forming fixed-sized satellite/wireless frames, each containing pluralspackets and a variable number of error correction code bytes; andtransmitting the satellite/wireless frames over the satellite orwireless network.
 2. The method according to claim 1, further comprisingthe step of compressing the spackets prior to forming thesatellite/wireless frames.
 3. The method according to claim 1, whereinsaid prioritizing step includes queuing the spackets in a plurality ofdata queues as a function of priorities of the frame relay packets towhich the spackets correspond.
 4. The method according to claim 3,wherein the plurality of queues correspond to different priority levels.5. The method according to claim 3, wherein the plurality of queuescorrespond to a plurality of virtual channels.
 6. The method accordingto claim 1, wherein said segmenting step includes segmenting the payloaddata of each of the frame relay packets into plural spackets, whereinall of the plural spackets, except a last of the plural spackets, isrequired to be n bytes in length, where n is an integer.
 7. The methodaccording to claim 1, wherein said segmenting step includes prependingeach spacket with a header.
 8. The method according to claim 7, whereinthe header of each spacket includes: a packet number indicating to whichframe relay packet the spacket corresponds; a sequence number indicatingthe position of the spacket within the frame relay packet; a VC Id fieldindicating the virtual channel to which the frame relay packetcorresponds; and a last field indicating whether or not the spacket isthe last spacket in the frame relay packet.
 9. The method according toclaim 8, wherein a VC identifier contained in the VD Id field iscompressed from a VC identifier contained in the frame relay packet. 10.The method according to claim 1, wherein the spackets contained within asatellite/wireless frame are variable in size.
 11. The method accordingto claim 1, wherein a single spacket is transmittable over pluralsatellite/wireless frames.
 12. The method according to claim 1, whereinsaid forming step includes forming an interleaver frame from pluralsatellite/wireless frames, wherein the order of the bytes in theinterleaver frame is rearranged to spread the effects of burst errorsover several satellite/wireless frames.
 13. The method according toclaim 1, further comprising the step of monitoring the condition of alink over the satellite or wireless network, wherein said forming stepfurther comprises varying the variable number of error correction codebytes in response to variations in link conditions observed in saidmonitoring step.
 14. The method according to claim 13, wherein saidmonitoring step includes calculating a byte error ratio and said formingstep includes setting the number of error correction code bytes as afunction of the byte error ratio.
 15. The method according to claim 14,wherein the byte error ratio is calculated more quickly when the biterror rate is high and more slowly when the bit error rate is low. 16.The method according to claim 14, wherein the error correction codebytes are Reed-Solomon coding check bytes.
 17. The method according toclaim 14, wherein the error correction code bytes are Reed-Solomoncoding check bytes and Viterbi control codes.
 18. The method accordingto claim 1, wherein each fixed-sized satellite/wireless frame formed insaid forming step includes: a header, a payload comprising a variablenumber of variable-size spackets, and the variable number of errorcorrection code bytes.
 19. The method according to claim 18, wherein theheader of each satellite/wireless frame includes: a field indicating thenumber of spackets in the frame; a field indicating a size of a firstpartial spacket in the frame; a field indicating a sequence number ofthe frame; a field indicating the number of error correction code bytesin the frame; a field indicating the number of error correction codebytes to be used in frames to be received; and a field indicatingwhether the spackets in the frame are compressed.
 20. The methodaccording to claim 19, wherein the field indicating the number of errorcorrection code bytes in the frame, the field indicating the number oferror correction code bytes to be used in frames to be received, and thefield indicating whether the spackets in the frame are compressed areinserted in a same field location in frames having different framenumbers.
 21. The method according to claim 18, wherein the errorcorrection code bytes are Reed-Solomon coding check bytes.
 22. Themethod according to claim 1, further comprising the steps of: receivingsatellite/wireless frames from the satellite or wireless network;resequencing the spackets contained in the received satellite/wirelessframes and reassembling the frame relay packets from the resequencedspackets; and transmitting the reassembled frame relay packets to theframe relay network.
 23. The method according to claim 22, furthercomprising the step of decompressing the spackets prior to resequencingthe spackets.
 24. A system for processing frame relay data to betransported over a satellite or wireless network, comprising: a framerelay physical and data link layer processor for receiving frame relaypackets from a frame relay network; a prioritizer for prioritizing theframe relay packets; a segmentation processor for segmenting the payloaddata of each of the frame relay packets to form spackets; a schedulerfor scheduling transmission of the spackets in accordance withpriorities of the frame relay packets to which the spackets correspond;and a satellite/wireless frame processor adapted to form fixed-sizedsatellite/wireless frames to be transmitted over the satellite orwireless network, each of the fixed-sized satellite/wireless framesincluding a variable number of error correction code bytes.
 25. Thesystem according to claim 24, further comprising a data compressor forcompressing the spackets prior to formation of the satellite/wirelessframes.
 26. The system according to claim 24, wherein said prioritizerqueues the spackets in a plurality of data queues as a function ofpriorities of the frame relay packets to which the spackets correspond.27. The system according to claim 26, wherein the plurality of queuescorrespond to different priority levels.
 28. The system according toclaim 26, wherein the plurality of queues correspond to a plurality ofvirtual channels.
 29. The system according to claim 24, wherein saidsegmentation processor segments the payload data of each of the framerelay packets into plural spackets, wherein all of the plural spackets,except a last of the plural spackets, is required to be n bytes inlength, where n is an integer.
 30. The system according to claim 24,wherein said segmentation processor prepends each spacket with a header.31. The system according to claim 30, wherein the header of each spacketincludes: a packet number indicating to which frame relay packet thespacket corresponds; a sequence number indicating the position of thespacket within the frame relay packet; a VC Id field indicating thevirtual channel to which the frame relay packet corresponds; and a lastfield indicating whether or not the spacket is the last spacket in theframe relay packet.
 32. The system according to claim 31, wherein a VCidentifier contained in the VD Id field is compressed from a VCidentifier contained in the frame relay packet.
 33. The system accordingto claim 24, wherein the spackets contained within a satellite/wirelessframe are variable in size.
 34. The system according to claim 24,wherein a single spacket is transmittable over plural satellite/wirelessframes.
 35. The system according to claim 24, wherein saidsatellite/wireless frame processor forms an interleaver frame fromplural satellite/wireless frames, wherein the order of the bytes in theinterleaver frame is rearranged to spread the effects of burst errorsover several satellite/wireless frames.
 36. The system according toclaim 24, wherein said satellite/wireless frame processor monitors thecondition of a link over the satellite or wireless network and variesthe variable number of error correction code bytes in response tovariations in link conditions.
 37. The system according to claim 36,wherein said satellite/wireless frame processor calculates a byte errorratio and sets the number of error correction code bytes as a functionof the byte error ratio.
 38. The system according to claim 37, whereinthe byte error ratio is calculated more quickly when the bit error rateis high and more slowly when the bit error rate is low.
 39. The systemaccording to claim 36, wherein the error correction code bytes areReed-Solomon coding check bytes.
 40. The system according to claim 36,wherein the error correction code bytes are Reed-Solomon coding checkbytes and Viterbi control codes.
 41. The system according to claim 24,wherein each fixed-sized satellite/wireless frame includes: a header, apayload comprising a variable number of variable-size spackets, and thevariable number of error correction code bytes.
 42. The system accordingto claim 41, wherein the header of each satellite/wireless frameincludes: a field indicating the number of spackets in the frame; afield indicating a size of a first partial spacket in the frame; a fieldindicating a sequence number of the frame; a field indicating the numberof error correction code bytes in the frame; a field indicating thenumber of error correction code bytes to be used in frames to bereceived; and a field indicating whether the spackets in the frame arecompressed.
 43. The system according to claim 42, wherein the fieldindicating the number of error correction code bytes in the frame, thefield indicating the number of error correction code bytes to be used inframes to be received, and the field indicating whether the spackets inthe frame are compressed are inserted in a same field location in frameshaving different frame numbers.
 44. The system according to claim 41,wherein the error correction code bytes are Reed-Solomon coding checkbytes.
 45. The system according to claim 24, further comprising: areceive satellite/wireless frame processor for receivingsatellite/wireless frames from the satellite or wireless network; areassembly and resequencer processor for resequencing the spacketscontained in the received satellite/wireless frames and reassembling theframe relay packets from the resequenced spackets; wherein said framerelay physical and data link layer processor transmits the reassembledframe relay packets to the frame relay network.
 46. The system accordingto claim 45, further comprising a data decompressor for decompressingthe spackets prior to resequencing the spackets.